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STATING THE MANAGEMENT CHALLENGE 


HOW CAN THE TRADITIONAL PRACTICE OF 
SYSTEMS ENGINEERING MANAGEMENT, 
INCLUDING REQUIREMENTS SPECIFICATION, 

BE ADAPTED, ENHANCED, OR MODIFIED 
TO BUILD FUTURE PLANNING AND SCHEDULING SYSTEMS 
THAT POSSESS LIFECYCLE EFFECTIVENESS? 
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DISSECTING THE MANAGEMENT CHALLENGE 


TRADITIONAL SYSTEMS ENGINEERING MANAGEMENT PROCESS 









DISSECTING THE MANAGEMENT CHALLENGE 

REDESIGNING THE SYSTEM BASED ON OPERATIONAL EXPERIENCE 



DISSECTING THE MANAGEMENT CHALLENGE 


PLANNING AND SCHEDULING SYSTEMS 


ANY HUMAN-COMPUTER DECISION-SUPPORT SYSTEM THAT DETERMINES 
AND / OR REDETERMINES HOW SHARED RESOURCES WILL BE MANAGED 


OVERTIME 


ON-ORBIT 

SPACECRAFT 


PLATFORMS 

INSTRUMENTS 


EXPERIMENTS 

ASTRONAUTS 


LAUNCHES 

LAUNCH PADS 
LAUNCH VEHICLES 
PAYLOADS 

COMMUNICATIONS 



ACCURATE AND TIMELY ASSIGNMENTS (AND 
REASSIGNMENTS) OF RESOURCES 
IDENTIFICATION, AVOIDANCE, AND I OR 
RESOLUTION OF CONFLICTS 
EFFECTIVE AND COMPLEMENTARY HUMAN / 
COMPUTER INTERACTION 
UNCOMPLICATED AND STRAIGHT FORWARD 
HUMAN / HUMAN INTERFACE 


GROUND 

FACILrTIES 

COMPUTERS 

ANTENNAS 

OPERATORS 
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DISSECTING THE MANAGEMENT CHALLENGE 


SPACE OPERATIONS 



DISSECTING THE MANAGEMENT CHALLENGE 

LIFECYCLE EFFECTIVENESS 

OPERATIONAL EFFECTIVENESS 

DOING THE RIGHT JOB EFFICIENTLY 


EXTENSIBILITY 

EASY ACCOMMODATION OF CHANGE 
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RESPONDING TO THE MANAGEMENT CHALLENGE 

ADAPTATIONS TO THE TRADITIONAL PRACTICE OF 
SYSTEMS ENGINEERING MANAGEMENT 

FOR DOING THE RIGHT JOB EFFICIENTLY 

FOCUS SYSTEMS ENGINEERING EFFORT ON DEFINING AND BUILDING 
THE RIGHT SYSTEM, RATHER THAN ON DEFINING AND FOLLOWING THE 
RIGHT PROCESS 

KEY TO BUILDING THE RIGHT SYSTEM LIES IN DETERMINING AND 
IMPLEMENTING THE RIGHT REQUIREMENTS IN THE APPROPRIATE 
OPERATIONS CONTEXT 

10 ADAPTATIONS ARE RECOMMENDED 

FEATURED ARE: 

. REQUIREMENTS AND OPERATIONS CONCEPTS VALIDATION 
• PROTOTYPING 

. OPERATIONS CONSIDERATIONS AS EVALUATION CRITERIA 


RESPONDING TO THE MANAGEMEN T CHALLENGE 

ADAPTATIONS FOR DOING THE RIGHT JOB EFFICIENTLY 

1. ESTABLISH AND MAINTAIN COMPETING ALTERNATIVE OPERATIONAL CONCEPTS 

2 ADD OPERATIONAL EFFECTIVENESS CRITERIA TO THE EVALUATION PROCESS USCD IN 
REQUIREMENTS AND DESIGN REVIEWS 

3. START WITH GENERAL FUNCTIONAL REQUIREMENTS AS A BASELINE 

4 ADD OPERATIONAL EFFECTIVENESS TO CRITERIA FOR DESIGN ACCEPTABILITY 

5. UTILIZE FORMAL PROTOTYPING PLAN FOR CONTROL DURING SYSTEM DEVELOPMENT 

6. USE WORKING SOFTWARE AS DETAILED DESIGN DOCUMENTATION 

7. DEVELOP A TECHNIQUE FOR MAKING DECISIONS TO BORROW TOOLS, APPROACHES, OR 
SOFTWARE VS. BUILDING TOOLS, APPROACHES, OR SOFTWARE 

8. ENFORCE AN END-TO END IMPLEMENTATION STRATEGY - IMPLEMENT IN LAYERS HOT 
SEGMENTS 

9. FORMALLY ESTABLISH OPERATIONAL EFFECTIVENESS AS A TEST CRITERION 

10 DEVISE TEST PLANS WHICH CERTIFY OPERATIONAL EFFECTIVENESS IN REAL OR 

SIMULATED OPERATIONAL ENVIRONMENTS io 

I ■ H) 
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RESPONDING TO THE MANAGEMENT CHALLENGE 


ADAPTATIONS TO THE TRADITIONAL PRACTICE OF 
SYSTEMS ENGINEERING MANAGEMENT 

FOR EASY ACCOMMODATION OF CHANGE 


ELEVATE REQUIREMENTS SPECIFICATION FROM INDIVIDUAL SYSTEM 
LEVEL TO CLASS LEVEL 

• REQUIREMENTS AT THIS LEVEL CAN BE PRECISE AND UNAMBIGUOUS 

• GENERAL ARCHITECTURE EXISTS AT THIS LEVEL TO INCORPORATE 
NEW REQUIREMENTS 

RECOGNIZE GENERAL CASE / SPECIAL CASE RELATIONSHIPS AND 
DESIGN FOR GENERAL CASE 


5 ADAPTATIONS ARE RECOMMENDED 


RESPONDING TO THE MANAGEMENT CHALLENGE 
REQUIREMENTS SPECIFIED AT THE CLASS LEVEL 


SOME REQ’MTS 
AT THIS LEVEL 
MAYBE: 

• INCOMPLETE 

• AMBIGUOUS 

• UNQUANTIFIABLE 

• DYNAMIC 



REQ’MTS AT 
THIS LEVEL CAN BE: 

• COMPLETE 

• UNAMBIGUOUS 

• MEASURABLE 
• STATIC 
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RESPONDING TO THE MANAGEMENT CHALLENGE 


REQUIREMENTS NEED TO BE ELEVATED 


TRANSITION TO A GENERALIZED DESCRIPTION OF PLANNING AND SCHEDULING 


IFMM 


. CREWTIME, POWER, WATER 
. EXPERIMENT PERFORMANCE 
. SLEEP/ EAT CYCLES 


L6VE0. 


TO 


. RESOURCES 
• ACTIVITIES 

. GENERAL TEMPORAL RELATIONS 


IPLAMIK)© & ©^IISMUM© 

©las© 
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RESPONDING TO THE MANAGEMENT CHALLENGE 

ADAPTATIONS FOR EASY ACCOMMODATION OF CHANGE 

1. CHOOSE TOOLS THAT ARE DATA AND RULE-DRIVEN 

2 INCLUDE CODE STRUCTURE ASSESSMENTS AS A FORMAL PART 
OF DESIGN REVIEWS - FIND MODULES WITH SIMILAR 
FUNCTIONALITY AND GENERALIZE TO ELIMINATE ’’DUPLICATES" 

3. REVIEW DESIGNS FOR INTERPRETATIONS OF REQUIREMENTS 
THAT UNNECESSARILY LIMIT ENHANCEMENTS OR EXTENSIONS 


4. PERMIT MACHINE DEPENDENCY ONLY WHEN STRONGLY JUSTIFIED 


5. DEVELOP AN EVOLUTIONARY ACQUISITION STRATEGY DESIGNED 
FOR MULTIPLE CYCLES OF DESIGN AND IMPLEMENTATION 
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RESPONDING TO THE MANAGEMENT CHALLENGE 

RETROSPECTIVE ASSESSMENT OF HOW ADAPTATIONS WERE UTILIZED 






1 

COMPETING OPS CONCEPTS 

O 

UHK 

• 

2 

USE OF GENERAL REQUIREMENTS 

© 

© 

© 

3 

OPS EFFECTIVENESS CRITERIA IN SRR 

• 

UNK 

© 

4 

OPS EFFECTIVENESS CRITERIA IN PDR, CDR 

• 

UNK 

© 

5 

PROTOTYPING PLAN 

© 

© 

• 

6 

WORKING SOFTWARE AS SPECIFICATION 

• 

UNK 

© 

7 

BUILD v* BORROW CRITERIA 

o 

UNK 

© 

8 

END-TO-END IMP STRATEGY 

• 

© 

• 

9 

OPS EFFECTIVENESS AS TEST CRITERIA 

• 

UNK 

o 

10 

TEST IN OPERATIONAL ENVIRONMENT 

• 

© 

• 





1 

DATA- AND RULE-DRIVEN 

• 

0 

• 

2 

CODE STRUCTURE ASSESSMENTS 

• 

UNK 

• 

3 

PERFORMANCE LIMITATION REVIEWS 

• 

0 

• 

4 

MACHINE INDEPENDENCE 

© 

© 

© 

5 

EVOLUTIONARY ACQUISITION 

• 

© 

• 


KEY: # USED © PARTIALLY USED Q NOT USED 


EVALUATION BASED ON OPERATIONAL EFFECTIVENESS HIGH MODERATE HIGH 

EVALUATION SYSTEM BASED ON EXTENSIBILITY HIGH LOW HIGH -15- 
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FOCUSING THE TECHNICAL PERSPECTIVE 

ADAPTATIONS FOR DOING THE RIGHT JOB EFFICIENTLY 



2. ADD OPERATIONAL EFFECTIVENESS CRITERIA TO THE EVALUATION PROCESS USED IN 
REQUIREMENTS AND DESIGN REVIEWS 



4. ADD OPERATIONAL EFFECTIVENESS TO CRITERIA FOR DESIGN ACCEPTABILITY 

5. UTILIZE FORMAL PROTOTYPING PLAN FOR CONTROL DURING SYSTEM DEVELOPMENT 

6. USE WORKING SOFTWARE AS DETAILED DESIGN DOCUMENTATION 

7. DEVELOP A TECHNIQUE FOR MAKING DECISIONS TO BORROW TOOLS, APPROACHES, OR 
SOFTWARE VS. BUILDING TOOLS, APPROACHES, OR SOFTWARE 

8. ENFORCE AN END-TO-END IMPLEMENTATION STRATEGY - IMPLEMENT IN LAYERS NOT 
SEGMENTS 

9. FORMALLY ESTABLISH OPERATIONAL EFFECTIVENESS AS A TEST CRITERION 


10. DEVISE TEST PLANS WHICH CERTIFY OPERATIONAL EFFECTIVENESS IN REAL OR 
SIMULATED OPERATIONAL ENVIRONMENTS 
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FOCUSING THE TECHNICAL PERSPECTIVE 

ADAPTATIONS FOR EASY ACCOMMODATION OF CHANGE 



2. INCLUDE CODE STRUCTURE ASSESSMENTS AS A FORMAL PART OF 
DESIGN REVIEWS - FIND MODULES WITH SIMILAR FUNCTIONALITY AND 
GENERALIZE TO ELIMINATE ’•DUPLICATES" 



4. PERMIT MACHINE DEPENDENCY ONLY WHEN STRONGLY JUSTIFIED 

5. DEVELOP AN EVOLUTIONARY ACQUISITION STRATEGY DESIGNED FOR 
MULTIPLE CYCLES OF DESIGN AND IMPLEMENTATION 

-17- 
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SUMMARY 


. TRADITIONAL PRACTICE OF SYSTEMS ENGINEERING MANAGEMENT 
ASSUMES REQUIREMENTS CAN BE PRECISELY DETERMINED AND 
UNAMBIGUOUSLY DEFINED PRIOR TO SYSTEM DESIGN AND 
IMPLEMENTATION; PRACTICE FURTHER ASSUMES REQUIREMENTS 
ARE HELD STATIC DURING IMPLEMENTATION 

• HUMAN-COMPUTER / DECISION SUPPORT SYSTEMS FOR SERVICE 
PLANNING AND SCHEDULING APPLICATIONS DO NOT CONFORM WELL 
TO THESE ASSUMPTIONS 

ADAPTATIONS TO THE TRADITIONAL PRACTICE OF SYSTEMS 
ENGINEERING MANAGEMENT ARE REQUIRED 

FOR OPERATIONAL EFFECTIVENESS: DOING THE RIGHT JOB EFFICIENTLY 
FOR EXTENSIBILITY: EASY ACCOMMODATION OF CHANGE 

• BASIC TECHNOLOGY EXISTS TO SUPPORT THESE ADAPTATIONS 

• ADDITIONAL INNOVATIONS MUST BE ENCOURAGED AND NURTURED 

• CONTINUED PARTNERSHIP BETWEEN THE PROGRAMMATIC AND 
TECHNICAL PERSPECTIVE ASSURES PROPER BALANCE OF THE 
IMPOSSIBLE WITH THE POSSIBLE 
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PRESENTATION OUTLINE 


PART I: A PROGRAMMATIC PERSPECTIVE 

• STATING THE MANAGEMENT CHALLENGE 

• DISSECTING THE MANAGEMENT CHALLENGE 

• RESPONDING TO THE MANAGEMENT CHALLENGE 

• FOCUSING THE TECHNICAL PERSPECTIVE 

• SUMMARY 


PART II: A 


TECHNICAL PERSPECTIVE 

REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 
GOOD AND BAD STARTING POINTS FOR THE DESIGN 

CONCEPTS G ™ E C0NSEQUENCES OF OPERATIONS 
SUMMARY 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 

CHARACTERISTIC: THE MERIT OF A PLAN IS DIFFICULT TO QUANTIFY- 

PLANS USUALLY REPRESENT "ACCEPTABLE 
COMPROMISES" 


QUANTIFIABLE: 


MAX P = f (START TIME, RESOURCE UTILIZATION, SATISFIED 


REQUESTS) 


NON-QUANTIFIABLE: 

• JOE LIKES IT AND HE USED TO DO THE PLANNING 

• EVERYBODY CAN LIVE WITH IT 

• IT'S OK IF NEXT WEEK THE OTHER USERS CAN HAVE . . . . 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE MERIT OF A PLAN IS DYNAMIC 



• CIRCUMSTANCES CHANGE 


• MERIT MIGHT BE FUNCTION OF HOW THE PLANS LOOK 
OVER SEVERAL PLANNING HORIZONS 


REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE MERIT OF PLAN IS DEPENDENT ON THE PROCESS 

USED TO GENERATE IT. 



NO INFORMATION 
ABOUT PROCESS 


PROCESS INFORMATION 
PROVIDED 


MERIT OF THE 
PLAN ' CHANGES’ 


• SAME PLAN LOOKS GOOD OR BAD DEPENDING ON NUMBER 
OF ALTERNATIVES EXAMINED 

• MERIT OF PLAN CANNOT BE DETERMINED FROM THE 
INFORMATION IN THAT PLAN 

• MERIT IS PROCESS NOT PRODUCT DEPENDENT 

• THIS CHARACTERISTIC IS FUNDAMENTALLY AND CRITICALLY 
DIFFERENT FROM ENGINEERING SYSTEMS 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE INFORMATION FLOW CONTENT BETWEEN 

SERVICE REQUESTER AND THE PLANNER ARE VERY 
DIFFICULT TO PREDICT 


THEN N E xB HE = T °c TAL INF0RMAT,0N < IN BITS > NEEDED TO RESOLVE THE RESOURCE ALLOCATION; 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE TIME REQUIRED TO BUILD A PLAN IS LONGER 

THAN ORIGINALLY PREDICTED 



DESIGNED PLANNING HORIZON 

• Tp IS THE TOTAL PLANNING AND REPLANNING TIME IN HORIZON K FOR 
ACTIVITIES TO OCCUR IN HORIZON K + 1 

• Hp IS THE LENGTH OF THE PLANNING HORIZON 

• CLEARLY Tp/Hp < 1 TO MAINTAIN OPERATIONS 

• WHAT SHOULD BE THE DESIGN VALUE OF Tp/Hp? 
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REQUIREMENTS THAT ARE UNLIKE OTHER SYSTEMS 


CHARACTERISTIC: THE SEQUENCE OF PLANNING TASKS CANNOT BE 

DETERMINED AT DESIGN TIME 



TASK SEQUENCE DETERMINABLE TASK SEQUENCE DETERMINABLE 

AT DESIGN TIME AT TASK PERFORMANCE TIME 


GOOD AND BAD STARTING POINTS FOR THE DESIGN 


• DESIGN THE SYSTEM AS A REPLANNING SYSTEM 


- REPLANNING IS A MORE FREQUENT TASK IN MOST OPERATIONAL 
ENVIRONMENTS 

- PLANNING CAN BE ACCOMMODATED AS A SPECIAL CASE OF 
REPLANNING 


- FIRST COME / FIRST SERVED ALLOCATION (i.e., DEMAND 

ASSIGNMENT) CAN BE ACCOMMODATED AS A SPECIAL CASE OF 
PLANNING 
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GOOD AND BAD STARTING POINTS FOR THE DESIGN 


• DESIGN THE SYSTEM INITIALLY TO ALLOW HUMANS TO MAKE ALL 
DECISIONS 


- ALGORITHMS SHOULD BE DESIGNED TO EMULATE HUMAN 
DECISION BEHAVIOR 


- ONLY DECISION MAKING THAT IS DETERMINED TO BE ROUTINE 
SHOULD BE DELEGATED TO THE MACHINE 


- OPERATIONAL EXPERIENCE IS NEEDED TO DETERMINE WHICH 
DECISIONS ARE ROUTINE 
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GOOD AND BAD STARTING POINTS FOR THE DESIGN 

• DESIGN THE SYSTEM ORIGINALLY TO HANDLE POOLED RESOURCES 

- POOLED RESOURCES CAN ACCOMMODATE ANY QUANTITY OF A 
SHARED RESOURCE 


INDIVIDUAL RESOURCES CAN BE ACCOMMODATED AS A SPECIAL 
CASE OF POOLED RESOURCES 
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GOOD AND BAD STARTING POINTS FOR THE DESIGN 


• DESIGN THE SYSTEM ORIGINALLY TO HANDLE GENERAL TEMPORAL 
RELATIONSHIPS 

- ACCOMMODATE NUMEROUS SEQUENCE RELATIONSHIPS AS 
SPECIAL CASES 

— PREDECESSOR / SUCCESSOR RELATIONSHIPS 
— MINIMUM SEPARATION 
— MAXIMUM SEPARATION 
-- MINIMUM OVERLAP 
— MAXIMUM OVERLAP 
— SPECIFIED OVERLAP 

- - ONE ACTIVITY ANY TIME DURING ANOTHER 
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PROJECTING THE CONSEQUENCES OF 
OPERATIONS CONCEPTS 


• UNDERSTANDING OUR PROBLEM DOMAIN IS VERY IMPORTANT 

- EXAMPLE: SNC /S NOT PRIMARILY 

— A S/C CONTROL CENTER 
— A COMMUNICATIONS SYSTEM 
- - A COMMAND AND CONTROL FACILITY 
SNC IS 

— A DECISION SUPPORT SYSTEM 
-- A SERVICE PLANNING CENTER 
— A SERVICE PROVIDER/FACILITATOR FOR USERS 

- THE RIGHT TECHNIQUES FOR THE WRONG DOMAIN WON'T HELP 

• THE DESIGN CONSEQUENCES OF AN OPERATIONS CONCEPT CAN BE 
PREDICTED 

- SEEMINGLY APPROPRIATE CONCEPTS CAN LEAD TO 
UNACCEPTABLE COSTS, COMPLEXITIES, etc. 

- A METHODOLOGY FOR PREDICTING THE DESIGN CONSEQUENCES 
OF AN OPERATIONS CONCEPT HAS BEEN DEVELOPED 
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PREDICTING DESIGNS FROM OPERATIONS CONCEPTS* 
AN EXAMPLE 


OPS CONCEPTS "DIMENSIONS” 

• HUMAN/COMPUTER DECISION 
ROLES 

• NUMBER OF USER-TO-SERVICES 
INTERFACES 

• USER-TO-CENTER COMMUNICATION 
STYLES 

• REPLANNING PHILOSOPHY 

• REQUEST SATISFACTION GOALS 

• USER KNOWLEDGE OF TDRS 

• USER KNOWLEDGE OF NETWORK 

• SERVICE CONFIRMATION RESPONSE 

• RELIABILITY OF SERVICES 

• SECURITY OF USERS 

• PERCEIVED ABUNDANCE OF 
RESOURCES 

• PERCEIVED COMPLEXITY OF 
DECISIONS 

• DEVELOPMENT vs OPERATIONAL 
COST TRADEOFFS 
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USE DIGITAL 
MSG'S FOR COMM 
FAULT ISOLATION 
IN NCC 

SCHEDULE BY 
PRIORITY 

FEED SERVICE 
ACCT'G BACK TO 
SCHEDULER 
PERIODICALLY 


SUMMARY 

PAST PROBLEMS HAVE THE FOLLOWING ORIGINS: 

R EQ LN R E M E N TS^j FOR* P LANNMG ^A N D^SCH E D U LU^G) ^ ^ R E OF THE 

' (GENERAL CaIeS^FoI THE d1sK3N^ G P °' NT ASSUMPTI0NS 

• NOT UNDERSTANDING THE TYPE OF SYSTEM THAT WE’RE BUILDING 

* USIi , . N J? ERSTANDING THE DESIGN CONSEQUENCES OF THE 
OPERATIONS CONCEPT SELECTED 


THE GOOD NEWS IS THAT WE: 

• NOW HAVE MORE SUCCESSFUL SYSTEMS TO EXAMINE 

• NOW HAVE A GOOD COLLECTION OF CLASS-LEVEL REQUIREMENTS 

* .Frf£?®^ E THE GENERAL CASES THAT ACCOMMODATE THE 
cDcni?i E oAeJi FR0M A particular DOMAIN AS PARAMETRIC 

orbUAL CASES 

* T0 PREDICT the consequences of ops concept 

ALTERNATIVES 
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